Use Case Scenario:

Normal Priority

When the mode attribute in the <Push> tag is set to normal, the telephone state for the Display push type is as follows:

When the telephone is in any of the non-pushable states, the screen currently displayed continues to be displayed (i.e., the Display push is rejected).
If the telephone is in the pushable state, the telephone accepts the Push Message and generates appropriate notification tone(s).

A normal push is accepted when the telephone is in text edit mode in applications other than the Web. If a non-Web application, such as Contacts, is in text-edit mode, then x-Push-Status 204 “Not in Push State: Push Accepted” is sent:


Parameter	Status Code	Reason Phrase
HTTP Status Code	200	“OK”
x-Push-Status	204	“Not in Push State: Push Accepted”


Use Case Scenario: Q. What happens when a user is editing or adding an entry on the Contacts screen and a normal priority Display push Message is sent? A. If an alert is associated with this message, then the alert sounds first. The pushed content is loaded in the background. The message is not displayed until the user elects to view it by clicking the Web tab to launch the Web browser.

If the Web is in “text edit mode” a subsequent normal push is rejected and x-Push-Status 205 “Not in Push State: Push Aborted” is sent. The Push Request does not proceed.


Parameter	Status Code	Reason Phrase
HTTP Status Code	200	“OK”
x-Push-Status	205	“Not in Push State: Push Aborted”

NOTE: If a normal Display push is denied, then the entire Display push is denied, including the Web page’s title. Hence, the application writer might choose to send two pushes - a Top Line push, followed by a Display push. Sending two messages maximizes the chance of the user viewing at least one message.